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1 .  INTRODUCTION 

Most  of  the  work  in  mechanical  program  verification  is 
based  on  the  method  of  invariant  assertions  [5].  The  automatic 
discovery  of  invariant  assertions  from  given  program  specifica¬ 
tions  has  thus  been  a  matter  of  much  research,  e.g.  [1,2, 3, 6, 7, 
12,13,15].  The  general  problem  of  synthesizing  invariant 
assertions  is  deemed  unsolvable  [12],  and,  as  Wegbreit  [16] 
implies,  even  when  the  problem  is  solvable,  it  may  require  an 
exponential  amount  of  time  in  the  worst  case.  Our  result  is 
that  for  the  restricted  class  of  arithmetical  programs,  the 
problem  is  solvable  as  well  as  quite  simple.  Informally,  arith¬ 
metical  programs  are  those  in  which  values  and  operations  range 
over  non-negative  integers.  Most  data  types  of  practical  use 
can  be  represented  by  non-negative  integers  by  proper  mapping, 
and  hence  the  class  of  arithmetical  programs  is  quite  large. 

As  an  alternative  to  the  second-order  predicate-calculus 
formalization  of  flowchart  programs,  developed  by  Cooper  [2] 
and  Manna  (see  [9]),  we  formalize  arithmetical  flowchart  programs 
in  terms  of  Godel's  classical  arithmetical  predicates  (see  [8]) 

—  a  first-order  theory  containing  equality,  zero,  successor, 
addition,  and  multiplication.  We  then  present  a  construction 
for  the  minimal  predicate  [9]  associated  with  any  cut-point  in 
a  given  arithmetical  program.  (A  minimal  predicate  for  a  cut- 
point  is  in  a  sense  the  strongest  invariant  assertion  at  that 
point.)  We  also  show  that  two  alternative  definitions  of 
invariant  assertions,  namely  by  minimal  predicates  [9]  and  optimal 
predicates  [3]  are  equivalent;  our  explicit  solution  for  a  minimal 
predicate  also  satisfies  the  definition  of  optimal  predicate. 

2.  ARITHMETICAL  PREDICATES  AND  PROGRAMS 

This  section  defines  and  relates  together  the  concepts  of 
arithmetical  predicates  and  arithmetical  flowchart  programs. 
Arithmetical  predicates  are  defined  following  the  treatment  in 
[8].  Informally,  arithmetical  predicates  are  properly  formed 
formulas  which  contain:  zero,  individual  variables,  successor, 


addition,  multiplication,  equality,  logical  connectives,  quanti¬ 
fiers  over  individuals.  The  formulas  may  also  contain  other 
symbols  that  can  be  defined  in  the  system.  For  example,  one  may 
abbreviate  O'  (the  successor  of  zero),  0'',  ...  by  1,  2,  ...» 
and3z  (x+z ' ) =y)  by  x<y,  etc.  A  function  f  is  arithmetical  if  the 
predicate  f(x)=y  is  arithmetical. 

The  notions  of  1-recursive  schemas  and  1-recursive  program 
are  defined  about  the  same  way  as  recursive  schemas  and  recursive 
programs  have  been  defined  in  the  literature  (e.g.  19],  except 
that  the  number  of  function  variables  is  restricted  to  one,  i.e., 
the  schemas  and  programs  are  restricted  to  a  single  use  of 
recursion.  A  1-recursive  program  is  arithmetical  if  it  is  ob¬ 
tained  by  interpreting  a  1-recursive  schema  over  the  domain  of 
non-negative  integers.  It  is  then  shown  that  the  computation 
associated  with  an  arithmetical  1-recursive  program  can  be 
stated  in  terms  of  an  arithmetical  predicate. 

The  result  is  then  extended  to  flowchart  programs  in 
general.  A  flowchart  program  is  called  arithmetical  if  it  is 
obtained  from  a  flowchart  schema  under  an  arithmetical  inter¬ 
pretation.  By  using  computation-preserving  translations  to 
obtain  a  1-recursive  program  from  any  flowchart  program,  it  is 
shown  that  the  computation  associated  with  a  flowchart  program 
can  be  characterized  by  an  arithmetical  predicate . 

2.1  Basic  notation  and  definitions 

The  symbols  from  which  our  formulas  are  constructed  are  the  following 

1.  Punctuation  marks  ,  (  ) 

2.  Truth  symbols  T  F 

3.  Logical  symbols  -v  3  &  v  3  V 

4.  Constants : 

2-adic  function  constants  *  + 

1- adic  function  constant  Succ 

2- adic  predicate  constant  = 

constant  0 

5 .  Variables : 

individual  variables  vl'v2,v3'*’’ 
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(For  simplicity,  we  may  use  additional  symbols  such  as  x,y,u  to 
denote  the  formal  individual  variables  v^.) 

We  define  recursively  three  classes  of  expressions  as  follows: 

Definition  1 

a)  p- terms : 

1.  0  is  a  p-term. 

2.  Each  individual  variable  is  a  p-term. 

3.  If  t^  and  t 2  are  p-terms,  then  so  are  +  t 2)  , 

(ti  *  t2)  and  Succft^). 

b)  Atomic  formulas: 

1.  T  and  F  are  atomic  formulas. 

2.  If  t^  and  t2  are  p-terms,  then  the  expression  (t^  =  t2) 
is  an  atomic  formula. 

c)  Arithmetical  predicates : 

1.  Each  atomic  formula  is  an  arithmetical  predicate. 

2.  If  R  is  an  arithmetical  predicate  and  x  is  a  variable,  then 

~(R),  3x(R)  and  Vk(R) 
are  arithmetical  predicates. 

3.  If  R  and  S  are  arithmetical  predicates,  then  so  are 

(R  3S),  (R  &  S)  and  (R  v  S) 

In  defining  an  atomic  formula,  term  and  arithmetical  predicate, 
we  use  more  parentheses  than  is  strictly  necessary  to  indicate 
the  scope  of  operators.  We  can  omit  some  of  them  by  employing 
the  usual  rank  conventions.  We  list  operators  in  the  order  of 
increasing  precedence  as  follows: 

3  &  v  ~  V  3  =  +  *  Succ 

This  allows  us  to  shorten  the  length  of  the  formulas.  Another 
kind  of  abbreviation  is  provided  by  introducing  a  new  symbol  with 
a  method  for  translating  an  expression  containing  the  new  symbol 
back  into  one  without  it.  For  example,  we  abbreviate  the  ex¬ 
pression 

"3v3  (Succ(v3)+v1>  *  v2"  by  "v1<v2" 

and 

"Succ (0) " ,  "Succ (Succ (0) ) " ,  ...  by  "  1  "  2  ",  ... 


Definition  2 

A  predicate  p  is  arithmetical  if  there  exists  an  arithmetical 
predicate  logically  equivalent  to  p.  A  function  f  of  n  arguments 
(n>0)  is  arithmetical  if  there  exists  an  arithmetical  predicate 
equivalent  to  f(v^,...,vn)  =  v  +^. 

The  notation  next  used  has  been  employed  by  Manna  [9, 
pp.  319-321]  to  define  more  general  schemas.  The  1-recursive 
schemas  used  here  are  syntactically  simpler  than  general  schemas, 
yet,  as  will  be  shown  later,  they  define  the  same  class  of  functions. 
The  syntax  for  1-recursive  schemas  makes  use  of  the  following 
symbols : 

1.  punctuation  marks  ,  (  ) 

2.  definition  symbol  *• 

3.  conditional  symbols  IF  THEN  ELSE 

4 .  Constants: 

n-adic  function  constants  f"  ,  i>l»  n>0 
n-adic  predicate  constants  p?  ,  i>l,  n^O 
undefined  value  -L 

A  0-adic  function  constnat  f?  is  called  an  individual  constant, 

1  n  , 

and  a  0-adic  predicate  constant  p^  is  called  a  propositional  constant. 

5 .  Variables 

individual  variables  x^,x2,...,  y1,y2r... 

output  variable  z 

function  variable  G 

Instead  of  f?  or  p?,  we  simply  write  ^  or  p^^  when  the 
number  n  of  arguments  is  clear  from  the  context.  For  simplicity, 
we  use  additional  symbols  to  denote  the  formal  ones,  e.  g.,  f,  g, 
h  for  function  constants,  p,  q  for  predicate  constants,  a,  b  for 
individual  constants,  etc.  The  context  will  make  such  useage 
clear.  We  also  use  the  vector  notation  for  conciseness.  For 
example,  we  write  x  for  a  vector  of  variables  x^,  ...»  xfi  for 
some  fixed  n. 
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We  define  recursively  three  classes  of  expressions  as  follows: 
Definition  3 

a)  s-terms: 

1.  Each  individual  variable  is  an  s-term. 

2.  If  t,  and  t,'  ,  ti  .  .. 

1  n  12  are  s-terms,  then  so  are 

fi(t1, ...,tn) 

and 

IF  pi(t1,  .  .  .  ,tn)  THEN  ELSE  t'2  . 

b)  conditional  terms 

1.  X  is  a  conditional  term. 

2.  Each  s-term  is  a  conditional  term. 

3.  If  t^,t2,...,tn  are  s-terms  and  wlfw2  are  conditional  terms 

then 

IF  ,tn)  THEN  W1  ELSE  w2 

is  a  conditional  term. 

c)  1-recursive  schemas 

A  1-recursive  schema  is  an  expression  of  the  form 

z=G(x,t(x))  where 

G(x,y)  4-  IF  p(x,y)  THEN  w(x,y) 

ELSE  G(x,t'(x,y)) 

Here  t(x),t'(x,y)  are  vectors  of  s-terms,  with  t(x)  having  the 
same  number  of  components  as  y,  and  w(x,y)  is  a  conditional  term. 
The  variables  x  and  y  are  called  input  and  program  variables, 
respectively. 

Given  a  1-recursive  schema  S,  we  can  specify  an  interpretation  I 
of  the  schema  in  terms  of: 

1.  A  set  D  called  the  domain  of  the  inerpretation. 

2.  Assignments  to  the  constants: 

To  each  function  constants  f”  a  total  function  mapping: 

Dn  -*•  D 

To  each  predicate  constant  p”  a  total  predicate  mapping: 

Dn  -*•  (F,T) 


Note  that  the  individual  constant  fV  or  a^  is  assigned  some 
fixed  element  of  D,  and  the  propositional  constant  p?  is  assigned 
the  value  T  or  F. 

The  pair  P=  <S,I>  ,  where  S  is  a  1-recursive  schema  and  I 
is  an  interpretation  of  S  is  called  a  1-recursive  program.  For 
given  values  of  x,  a  1-recursive  program  P=  <s,I>  can  be  executed 
by  constructing  the  sequence  of  s-terms  Sq,s^,...  as  follows: 

Sg=G(x,t(x))  after  all  possible  simplifications  (see  below) 

s^+^  is  obtained  from  s^  by  replacing  in  the  leftmost- inner¬ 
most  occurrence  of  G(x,t{x))  with 

v 

IF  p(x,t(x))  THEN  w(x,t (x) )  ELSE  G(x,t' (t (x) ) ) 
and  then  applying  all  possible  simplifications. 

The  simplification  rules  are 

a)  Replace  each  occurence  of  f^ft^...^)  and  pi  (t^^, . .  .tn)  / 
where  t^  is  an  element  of  the  domain  D,  by  its  value. 

b)  Replace 


and 

(IF 

T  THEN 

h 

ELSE 

t2) 

by  t 

(IF 

F  THEN 

h 

ELSE 

t2) 

by  t 

If  the 

computation 

sequence 

V 

t  •  •  • 

is 

finite,  ■ 

term  sk  is  not  JL  ,  we  say  val  <P,x>  =  s^;  otherwise  val  <P,x>  is 
undefined. 

Example  1  The  following  is  a  1-recursive  schema  with  one  input 
variable  x  and  two  program  variables  ylfy2: 

S:  z=G(x,x,a)  where 

G(x,y1»y2)  «■  IF  pfy^  THEN  y2 

ELSE  GU^f  (y^  ,q{y1,Y2)  ) 

Choose  the  interpretation  I  as  follows:  D={  0, 1,2 , . . . } ,  1  for  a, 
y^-O  for  p(y^) ,  f(y1)*y1“l  [define  f(0)=0  to  make  f  total], 

g(yi,y2)»yi*y2*  Then  we  obtain  the  following  1-recursive  program: 


P=(S,I):  z=G(x,x,l)  where 

G(x,ylfy2)  «■  IF  y^=0  THEN  1 

ELSE  G(x,y1~l,y1*y2) . 

For  the  initial  value  x-3,  the  computation  sequence  is  as  follows: 
s0=G(3,3,l),  s1=G(3,2,3)/  s2=G(3,l,6),  s4=G(3,0,6),  s5=6.  Thus, 

val  <P,3>  =  6.  In  general,  val  <P,x>  =  x! 

2.2  Program  characterization  by  arithmetical  predicates 

An  arithmetical  interpretation  of  a  recursive  schema  S  is  an 
interpretation  such  that 

1.  The  domain  D  is  the  set  of  non-negative  integers. 

2.  The  functions  and  predicates  assigned  to  the  function  and 
predicate  variables  of  S  are  all  arithmetical. 

An  arithmetical  1-recursive  program  is  a  1-recursive  program 
which  is  obtained  from  a  1-recursive  schema  under  an  arithmetical 
interpretation.  Thus,  I  and  (S,I)  used  in  the  example  above 
are  an  arithmetical  interpretation  and  an  arithmetical  1-recursive 
program,  respectively.  Now  we  can  state  the  main  result  of  this 
section. 

Theorem  1  Let  P  be  an  arithmetical  1-recursive  program.  Then 
val  <P,x>  =  u  is  an  arithmetical  predicate. 

Before  proving  the  theorem,  we  need  the  following: 

Lemma  1  Under  an  arithmetical  interpretation,  s-terms  and  condi¬ 
tional  terms  become  arithmetical  functions. 

Proof  First  suppose  t  is  an  s-term.  We  prove  by  induction  that 
t  is  arithmetical. 


Basis  t  is  some  individual  variable  x.  Then  t=u  is  equivalent  to 
x=u  which  is  an  arithmetical  predicate. 

Induction  step  t  is  f(t, ,...,t_)  and  all  t.=u.  are  arithmetical 

in  ii 

predicates.  Then  t=u  is  equivalent  to 

3yx* • •3yn(y1“t1&. • .&yn=tn  &  f(yx> . ..,yn)=u) 

which  is  an  arithmetical  predicate.  Suppose 

t  is  IF  p(t^)  THEN  t2  ELSE  t^  and  we  assume  that  t^,  t2,  and  t3 
are  arithmetical.  Then  t-u  is  equivalent  to 
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3y*.  &t2=u  v  ~p(y)  &  t3=u) ) 

which  is  an  arithmetical  predicate.  Next,  suppose  w  is  a  condi¬ 
tional  term.  Again  we  can  prove  by  induction  that  w  is  arithmetical. 

Basis  If  w  is  JL  then  w=u  is  equivalent  to 

X  =  u 

which  is  F  (since  the  domain  of  variable  is  0,1,....);  therefore  it 
is  an  arithmetical  predicate. 

Induction  step  Same  as  for  s-terms. 

Proof  of  Theorem  1  Let  the  program  P=(S,I)  be 

(1)  z=G(x,t(x))  where 

G(x,y)  4*  IF  p (x , y)  THEN  w(x,y) 

ELSE  G(x,t'(x,y)) 

Let  n  be  the  number  of  program  variables  in  P  (i.e.  the  number  of 
elements  in  y) .  Then  n  is  a  fixed  number  for  P.  With  the  ith 
term  in  the  computation  sequence  for  val<P,x>  ,  we  can  associate 
an  n-tuple  a1  such  that  the  jth  component  of  a1  gives  the  value 
of  the  program  variable  y^  at  the  ith  step  of  execution  in  <P,x>  . 
Then  for  val  <P,x>=  u  to  be  true,  there  must  exist  an  integer  k 
such  that 

0 

a  =  t (x) 

10  0 
a  =  t' (x,a  )  &  -p(x,a  ) 

2  1  1 
a  =  t' (x,a  )  &  ~p(x,a  ) 


(k-1)  (k— 2)  (k-2) 

a  =  t' (x,a  )  &  ~p (x,a  ) 

(k-1)  (k-1) 

u  =  w  (x,a  )  &  p (x,a  ) 

Godel  (see  [8])  has  introduced  the  arithmetical  function  8(u,v,i) 
with  the  properties: 

(i)  The  predicate  8(u,v,i)»w  is  arithmetical, 

(ii)  For  any  finite  sequence  of  natural  numbers  ng,n^, . . . ,n^, 
one  can  find  two  integers  c,d  such  that  8(c,d,i)=n^  for  i=0,l,...,k. 
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Note  that  a  suitable  definition  of  is 

8(u,v,i)  =  u  mod  (i+l)*v+l 

To  use  8  to  encode  arbitrarily  long,  finite  sequences  of  n-tuples, 

we  need  2n  constants  c, ,c_,...,c  ,d. ,d_ , .  . .  ,d  .  Let  us  denote 

l  i  n  i  z  n 

the  vectors  <c,  , . . .  ,c  >  ,  <d,  , . .  .  ,d  >  ,  and 

1  n '  ^  1  n 

<6(c1,d1,i) , . . . ,  8(cn,dn,i)>  by  c,d, 8(c,d,i) ,  respectively,  and 

denote 

3c1  . .  -3cn,  3d1  . .  .3dn  by  3c, 3d 

Then  we  may  write  (2)  as 
(3)  3k3c3d [8 (c,d,0)=t (x) 

&Vi[((Xi<k)  3[8(c,d,i)  =  t * (x, 8 (c ,d, i-1) ) 

&~lp(x,8  (c,d,i-l)  )  ]  ] 

&  u  =  w(x,  8  (c,d,k)  )  St  p(x,  8  (c,d,k) )  ] 

Being  equivalent  to  (3) ,  val  <P,x>  =  u  is  an  arithmetical  predicate. 

We  remark  that  it  is  only  for  simplicity  that  1-recursive 
schemas  have  been  defined  to  have  a  single  output  variable.  Their 
definition,  as  well  as  Theorem  1,  can  be  extended  to  the  case  of 
any  finite  number  of  output  variables. 

Example  2  As  seen  previously,  the  following  is  an  arithmetic 
1-recursive  program. 

P:  z=G(x,x,l)  where 

G(x,y1,y2)  if  y1=0  then  y2 

ELSE  G{x,yl-l,y1*y2) 

Here  G  is  arithmetical,  and  the  predicate  val(P,x)=u  is  equivalent 
to 

3k3c13c23dL3d2  [8(c1,d1,0)=x  &  B(c2,d2,0)-1 

Si  Vi[0<i<k  [BCCj^d^i)  =  8  ,dx ,  i-1) -1 

s>  8(c  2,d2'i)=  8(c^,d1,i-l)  *8  (c2  ,d2  ,  i-1) 

&  ~  8(c1,d1,i-l)=0]] 

&  u  =  8  (c2  ,d2 ,  k)  Si  SCc^d^k)  =  0] 
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2 . 3  Arithmetical  predicates  for  flowchart  programs 

The  formalization  in  terms  of  arithmetical  predicates 
obtained  above  for  1-recursive  programs  will  now  be  extended  to 
flowchart  programs  in  general.  The  reader  is  referred  to  [9] 
for  the  definition  of  flowchart  schemas,  flowchart  programs,  and 
the  computation  sequences  associated  with  flowchart  programs. 

We  define  an  arithmetical  flowchart  program  to  be  a  flowchart 
program  obtained  from  a  flowchart  schema  under  an  arithmetical 
interpretation . 


Lemma  2  Every  flowchart  program  can  be  translated  into  an 
equivalent  flowchart  program  with  at  most  one  loop. 

This  is  a  well  known  part  of  computer  science  folklore  but  its 
proof  is  not  commonly  available  in  print.  Similar  results  in¬ 
clude:  the  need  of  only  one  mu-operator  in  recursive  function 
theory  (see  (see  [8] ,  or  of  only  one  backward  GOTO  in  PL [11]. 


Proof  We  give  a  transformation  in  three  steps  as  follows: 

1)  Enumerate  all  statements,  viz.  associate  and  integer  i 
(i=l,2,...k)  with  every  assignment  statement  and  every 
test.  To  each  HALT  statement  assign  a  distinct  integer, 
^halt'  such  that  ^halt>k'  and  t0  each  L00p  statement  an 
integer  iloop  such  that  iloop>ihalt  for  all  i„alt> 


2)  From  each  statement  S^,  i=l,2,...,k,  obtain  the  statement 
S!^  as  follows: 

(The  number  j  associated  with  a  star  denotes  that  in  the 
original  flowchart  C  the  statement  following  this  point 
was  numbered  j . ) 


Si 


START 


y«-h(x) 

y  -j 


■*-* 


3)  The  flowchart  C'r  equivalent  to  the  original  flowchart  C 
is  then: 


Lemma  3  Every  flowchart  program  can  be  translated  into  an 
equivalent  1-recursive  program. 

Proof  Using  the  method  of  the  previous  lemma,  it  is  possible  to 
translate  a  flowchart  into  a  one-loop  flowchart.  Moreover,  the 
body  of  this  loop  does  not  contain  any  LOOP  statement,  and  can 
therefore  be  translated  into  an  expression  of  the  form 

IF  y  =  1  THEN  S' 
c  l 

ELSE  IF  y  =  2  THEN  Si 
C  2 

ELSE 

• 

.  IF  yc  =  k-1  THEN  S]^_1 

ELSE  S£ 

which  is  an  s-term.  The  segment  of  the  program  following  the 

termination  condition  (y  >k)  can  be  translated  as 

c 

IF  yc  =  iloop  THEN  X  ELSE  y 
which  is  a  conditional  term.  Now,  the  flowchart  C'  can  be 
translated  into  a  1-recursive  program  by  the  algorithm  of 
McCarthy  [10]  which  in  fact  is  not  restricted  to  one  loop. 
Theorem  2  Let  C  be  an  arithmetical  flowchart  program  with 
input  variables  x  .  Then 

the  predicate  val<C,x>  =  u  is  arithmetical. 

Proof  The  arithmetical  predicate  equivalent  to  val<C,x>  =  u 
can  be  constructed  in  the  following  way. 

1)  Translate  the  flowchart  C  into  flowchart  C'  containing  a 
single  loop,  using  the  method  of  Lemma  2 

2)  Translate  the  flowchart  C*  into  a  1-recursive  program  P 
using  McCarthy's  algorithm. 

3)  Translate  the  program  P  into  an  arithmetical  predicate 
using  the  method  of  Theorem  1. 

Let  us  denote  the  above  predicate  by  Rp(x,u).  This 
predicate  completely  characterizes  the  computation  of  P  on  input 
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x.  It  can  be  used  to  prove  various  properties  of  P.  Examples: 

(i)  P  halts  on  input  x  if  3uRp(x,u)  holds. 

(ii)  Given  an  "output  predicate"  A(x,z) ,  P  is  partially  correct 
with  respect  to  A  if  3u[Rp(x,u)  &  A(x,u)]  holds. 

We  point  out  that  in  the  work  of  Cooper  and  Manna  (see  [9] )  ,  a 
second-order  formula  is  associated  with  a  flowchart  and  the  proofs 
of  certain  properties  of  programs  in  their  formalization  may 
require  second-order  methods.  In  contrast,  Rp(x,u)  is  a  first- 
order  predicate. 

3.  SYNTHESIS  OF  INVARIANT  ASSERTIONS 

To  prove  the  partial  correctness  of  a  flowchart  program, 
one  often  needs  invariant  assertions  associated  with  various 
points  in  the  program.  These  are  predicates  involving  the 
variables  in  the  program  such  that  whenever  the  control  passes 
through  the  associated  point,  the  predicate  at  that  points  holds. 
Among  the  possible  assertions  at  a  point  in  the  flowchart  pro¬ 
gram,  there  exists  a  strongest  assertion  defined  as  follows 
(see  [9] )  : 

Definition  4  A  predicate  q^(x,y)  over  D  --  the  domain  of  inter¬ 
pretation  of  a  program  —  is  a  minimal  predicate  of  outpoint  i 
in  the  program,  if  q^(x,^*)  is  true  for  every  y*  from  D  such  that 
during  the  execution  of  <P,x>,  we  reach  the  outpoint  i  with  y=y*, 
and  for  no  other  y*'  is  q(x,y*')  true. 

Theorem  3  The  minimal  predicate  q^(x,y)  of  a  cutpoint  A  in  an 
arithmetic  flowchart  P  is  arithmetical. 

Proof  We  give  a  constructive  proof  as  follows.  First,  from  the 
program  P  we  obtain  another  program  P '  with  the  following  property 
P'  uses  a  new  variable  ynew  whose  value  at  the  cutpoint  i  equals 

the  number  of  times  the  cutpoint  i  is  passed  during  the  execution 
of  <P',x>.  For  any  integer  n,  if  during  the  execution  of  P,  a 
HALT  or  LOOP  statement  is  reached  before  the  cutpoint  A  is  passed, 
then  val  <  P' ,<  x,n>>  is  undefined.  Otherwise,  val  < P' ,< x,n>>  gives 
the  values  of  the  program  variables  y  when  A  is  reached  n  times. 
Next,  we  use  Theorem  2  to  obtain  the  arithmetical  predicate,  call 
it  (x # ,  n)  ,  equivalent  to 
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val  <P',<x,n^  *  y.  Finally,  we  show  that  the  required  minimal 
predicate  is  3np.  (x,y,n). 

X 

1)  From  the  program  P  construct  a  new  program  P'  as  follows: 

Let  y_,  2 1  be  new  variables  distinct  from  all  variables 
new 

in  P,  the  number  of  new  output  variables  z'  being  equal  to  the 
number  of  program  variables  y  in  P.  Then  replace 


^START^— » 

y-^h(x) 

with 

^STARTy— * 

y^h(x) 

y  ♦■o 

■'new 

_  ^ 

and  replace  all  HALT  statements 


2«-g(x,y)  — - ^HALT  ^ 


with 


Further,  replace  the  cutpoint  i 


i 

■ »  ■■■■  > 


with 
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2)  Using  the  method  of  Theorem  2,  derive  an  arithmetical 
predicate  P.  (x,y,n)  equivalent  to  val<P',<x,n»  =  y. 

3)  It  is  now  needed  to  show  that  the  predicate  3i  P^(x,^,n) 
is  equivalent  to  q. (x,y)  . 

Part  1:  3n  P^x^Sn) 

If  q^(x,y*)  is  true,  then  from  Definition  4  it  follows 
that  during  the  execution  of  <P,x>  the  cutpoint  i  was 
reached,  say  n*  times,  and  the  value  of  y  was  y*.  But 
then  3n  Pi(x,^*,n)  is  true  because  there  exists  an  n, 
namely  n*,  such  that  P^(x,y*,n*)  is  true. 

Part  2:  3n  P.(x,y*,n)  O  q. (x,y*) 

1  '**  ~  1  ~ 

Assume  3n  P^(x,^*,n)  is  true  and  let  n*  be  the  minimum 
n  such  that  Pi(x,^*,n)  is  true.  Then  q^x,^)  is  true 
because  there  is  a  point  in  the  execution  of  <P,x>  when 
i  is  reached  and  y  is  equal  to  y*,  namely  when  we  reach 
the  cutpoint  i  n*-time. 

As  indicated  by  the  above  theorem,  first-order  predicates 
suffice  for  expressing  invariant  assertions  for  arithmetic  pro¬ 
grams,  and  these  assertions  can  actually  be  generated  mechani¬ 
cally.  Also  note  that  the  Cooper-Manna  second-order  formulas 
[9]  associated  with  programs  contain  existential  quantifiers 
over  predicate  variables,  having  a  prefix  of  the  form  aQ^QjaQj... 
The  appropriate  to  satisfy  such  formulas  are  indeed  the  minimal 
predicates.  By  substituting  explicit  solutions  obtained  above, 
we  can  eliminate  the  second-order  prefixes  from  Cooper-Manna 
formulas.  Of  course,  such  a  reduction  to  first-order  formulas 
is  quite  involved.  It  is  also  unnecessary,  since  Theorem  1  fur¬ 
nishes  equivalent  first-order  formulas  directly. 
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Example  3  We  will  construct  the  minimal  predicate  for  the  cut- 


Applying  the  transformations  described  in  the  proof  of  the  Theorem 
3,  we  obtain  the  following  program: 


As  the  next  step,  we  can  use  the  method  of  Theorem  2  to  obtain 
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a  one-loop  flowchart  with  no  LOOP  statement  in  (or  attached  to) 
the  loop  body.  But  this  method  is  unnessary  for  our  simple 
example.  The  flowchart  already  has  only  one  loop,  and  all  we 
need  is  to  separate  the  LOOP  statement  from  the  body  of  the  loop. 
So  using  an  intuitively  correct  transformation,  we  transform  the 
above  flowchart  into: 


As  the  next  step,  using  McCarthy's  algorithm,  the  equivalent 
1-recursive  program  is  obtained: 

<z1,z2>  =  F(x1,x2,x2,0,0) 

P(xl,x2,y1,y2,ynew)*  IF  (y^O  v  y^-n) 

THEN  IF  y^O  THEN  X  ELSE  <y1»Y2> 

ELSE  F(x1,x2,y1-l,y2+x1,ynew+l) 

The  minimal  predicate  at  cutpoint  a  is  equivalent  to 
3n  val<C,<x,x2,n,x2,0,0>>  «  <Yi»Y2> 


and  is  given  by: 
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3n3k3c13c23c3  3d13d23d3 

[B(c1,d1,0)=x2  &  6(c2,d2,0)=0  &  g(c3,d3,0)=0 

&  Vi  [  (o<  i<  k)  3  [8(c1,d1,i)  =  6 (c1  ,d1 , i-1) -1 

&  8(c2,d2,i)  =  6(c2,d2,i-l)  +  x1 

&  $(c3,d3,i)  =  B(c3,d3,i)  +  1 

&  'v*  [  6(  ,d ,  i)  =  0  6(c3,d3,i)  =  n  ]  ]  ] 

&  Yl=6  (c-^d^k)  &  y2=S  (c2,d2,k)  &  $  (c-^dj^ ,k) 7*0)  ] 

This  predicate  is  the  minimal  predicate  for  the  cutpoint 
a,  because  it  describes  all  the  possible  values  of  the  variables 
y i  and  y2  at  a,  and  is  true  of  no  other  y.^  and  y2.  Using  the 
axioms  of  the  first-order  predicate  calculus  extended  with 
Peano  axioms,  we  can  simplify  this  predicate  to 

y2  =  Xl*<x2-yi)  t  CKy^  x2 

which  is  clearer  and  shorter  description  of  the  relation  between 
the  variables. 

4.  EQUIVALENCE  OF  MINIMAL  AND  OPTIMAL  PREDICATES 

The  problem  of  defining  and  discovering  inductive  asser¬ 
tions  has  been  explored  by  Cousot  and  Cousot  [3]  using  the  fixed- 
point  theory  of  programs .  They  describe  how  a  system  of  logical 
equations  can  be  associated  with  a  flowchart  such  that  the  least 
solution  of  this  system  of  equations  constitutes  optimal  invariant 
assertions.  Using  Tarski's  theorem  [14],  they  show  that  such 
assertions  always  exist.  But  because  of  their  non-constructive 
proof,  it  is  not  clear  how  to  obtain  the  solution  by  a  finite 
process.  We  prove  that  minimal  predicates  are  the  least  solution 
to  the  system  of  equations  defining  optimal  invariant  assertions, 
thus  showing  how  to  synthesize  optimal  invariant  assertions 
mechanically. 

Following  [3] ,  we  define  the  deductive  semantics  of  a 
programming  language  by  the  rules  associating  with  each  statement 
of  a  programming  language  an  equation  which  has  first-order 


predicates  as  indeterminates .  The  deductive  semantics  of  a 
program  is  defined  by  the  set  of  these  equations . 

The  basic  elements  of  a  flowchart  are: 

Start  statement: 


Assignment  statement: 


y«-f  (x,y) 


Test  statement: 


Merge  statement: 

*— 


* - 1 

Given  a  flowchart  we  assign  outpoints  to  this  flowchart 
so  that  there  are  only  basic  elements  between  outpoints.  Then 
we  associate  a  predicate  P^(x,y)  with  each  outpoint  i.  Finally 
with  each  basic  element  we  associate  one  or  two  equations  as 
follows: 

Start  statement: 


PQ(x,y)  ■  (y-h(x)) 


Assignment  statement:  j5 


y^f (x,y) 


P^X/y)  =  3v(Pj(x,v)  &  (y=f  (x,  v) ) ) 

where  P  ^ ,  respectively  P^,  are  predicates  associated  with 
cutpoints  j ,  respectively  i . 


Test  statement :  j 


P±(x,y)  =  Pk(x,y)  &  P j (x,y) 

Pk(x,y)  =  ^Pk(x,y)  &  Pj (x,y) 

where  P.  ,P.,P.  are  the  predicates  associated  respectively 

1  ]  JC 

with  cutpoints  i ,  j ,  and  k . 


Merge  statement:  j 


P^X/y)  *  Pj  (x,y)  v  Pk(x,y) 

where  P. ,P.  and  P,  are  predicates  associated  with  cutpoints 

X  ]  K 

i ,  j ,  and  k. 

By  applying  the  rules  of  deductive  semantics  to  a  flowchart, 
a  system  of  equations  of  the  following  form  is  obtained: 

PQ  =  (y=h  (x) ) 

P!  *  VVP1 . Pn>  ,5, 

P2  “  G2  ^P0'P1' * ' * *Pn^ 


Pn  *  Gn(P0'Pl' - V 


In  the  above  P^(x,y)  has  been  abbreviated  to  P^  for  convenience, 
It  is  possible  to  prove  that  the  set  of  first-order  pre- 


dicates  form  a  lattice  as  follows: 


3 

as 

the  ordering  relation 

F 

as 

the  least  element 

T 

as 

the  largest  element 

v (respectively  3) 

as 

join  for  finite  (respectively 
infinite)  operations. 

&  (respectively  V) 

as 

meet  for  finite  (respectively 
infinite)  operations. 

It  is  also  possible  to  prove  that  are  continuous  functions. 
It,  therefore,  follows  from  Tarski's  theorem  [14]  that  the 
above  system  (4)  has  a  least  solution  Popt. 

Theorem  4  Let  P  be  a  flowchart  program  with  input  variable  x. 
Let  G  be  the  set  of  the  equations  obtained  by  the  method  of 
deductive  semantics  as  described  above.  Then  the  minimal 
predicates  q^Xjy),  q2  (x,y)  ,  . . .  ,qn(x,y)  are  the  least  solution 
of  (4)  . 

Proof 

Part  1:  q(x,y)  =  < q1< x,y) ,q2( x,y) , . . . ,qn(  x,y) >  is  a  fixed-point 
of  G. 

By  case  analysis  . 

Let  the  ith  equation  of  the  set  G  of  the  equation  be: 

Case  1:  P^x^)  *  (y=h(x))  (5) 

This  equation  must  have  been  associated  with  the  START 
statement.  At  the  outpoint  1,  which  follows  START  and 
assignment  y-^h(x)  ,  the  only  possible  value  of  y  is  h(x)  . 
Therefore  the  minimal  predicate  q1(x,y),  describing  all 
(and  the  only)  possible  values  of  y  at  cutpoint  1,  is 
y*h(x).  When  we  substitute  this  q^(x,y)  in  the  equation 
(5)  we  obtain 

(y=h{  x) )  =  (y=h(  x) ) 

Thus  the  equation  is  satisfied. 

Case  2:  P^x^)  »3vPj(x,v)  &  y  -  f(x,v)  (6) 

This  equation  must  have  been  associated  with  the  assignment 
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statement  y«-f(x,y)  which  follows  cutpoint  j.  Suppose  the 
minimal  predicate  at  cutpoint  j  is  q^ (x,y) .  Then,  after 
the  execution  of  the  assignment  y«-f  (x,y) ,  all  (and  the 
only)  possible  values  of  y  at  cutpoint  i  are  those  values 
of  y  equal  to  f(x,v),  where  v  is  a  possible  value  of  y  at 
j.  In  other  words,  if  (x,y)  is  the  minimal  predicate  at 

cutpoint  j ,  the  minimal  predicate  at  cutpoint  i  must  be 

3v(qj(x,v)  &  y=f  (x,v) )  . 

If  we  substitute  these  q^  and  q^  into  the  equation  (6) , 
we  obtain 

3v(q.(x,y)  &  y=f  (x,v) ) )  =  3v<qj  (x,v)  &y=f(x,v))) 

Thus  the  equation  (6)  will  be  satisfied. 

Case  3:  Pi(x,y)  =  PL(x,y)  &  P..(x,y)  (7) 

This  equation  must  have  been  associated  with  the  test 
statement  that  follows  cutpoint  j.  Suppose  all  (and  the 
only)  possible  values  of  y  at  cutpoint  j  are  described  by 
qj (x,y) ,  then  in  order  to  arrive  at  cutpoint  i  we  had  to 
pass  test  p^(x,y).  Thus  all  (and  the  only)  possible  values 
at  cutpoint  i  are  described  by  the  predicate 

qj (x,y)  &  Px(x,y) 

Case  4s  Pi(x,y)  ■  Pj(x,y)  v  Pk(x,y)  (8) 

This  equation  was  associated  with  the  merge  statement.  Let 
qi(x,y)  and  qj (x,y)  describe  all  (and  the  only)  possible 
values  at  cutpoints  j  and  1.  To  arrive  at  cutpoint  i  we 
had  to  take  a  path  either  coming  from  cutpoint  j  or  from 
cutpoint  k.  Therefore  the  possible  values  of  variable  i  at 
cutpoint  i  are  either  those  at  cutpoint  j  or  k.  In  other 
words 

qi(x,y)  -  qj(x,y)  v  qk(x,y)  . 

The  predicates  q^,qj  and  qk  satisfy  the  equation  (8)  . 
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Part  2:  q(X/y)  is  the  least  fixed  point  of  G 
The  proof  is  by  contradiction.  Suppose 

~(q(x,y)  ZD  Q(x,y) ) 

where  Q(x,y)  is  a  fixed-point  of  G.  It  means  there  must 
exist  x* ,y*  and  cutpoint  i  such  that  q^(x*,y*)  is  true 
and  Q^(x*,y*)  is  false.  We  recall  from  Section  2.3  that 
if  q^(x*,y*)  is  true,  then  there  exists  a  statement  sequence 

S1 ,s2 '  *  *  * ,sk 

such  that  cutpoint  i  is  reached  and  the  value  of  y  at  this 

point  is  y*.  Let  S.  ,  S.  S.  be  the  statements 

*1  X2  xk 

executed,  and  y*  be  the  value  of  y  at  the  step  j .  We  first 
note  that 


Q.  (x*,y*  )oQ •  (x*,y*  )3Q.  (x*,y* 

1  12  2  3 

This  is  shown  in  the  following  lemma: 

Lemma  4  If  j>l  then 


Q,  (x*,y*  )ZD Q.  (x*,y*. ) 

j-1  j-1  j  j 

Proof :  By  case  analysis. 

Case  1:  Supposes^  is  an  assignment  statement.  Then 
Q,-  (x,y)  =  3v(Qj  (x,v)  &  y=f  (x,  v) )  .  If 

j  j-1 

Q.  (x*,y*  )  is  false,  then  Q.  (x*,y*  )  must  be 

j  j  Xj-1  j-1 


false .  But  we  know  that  there  is  a  v  such  that 
y*  =f(x*,v),  specifically  v=y*  .  Thus  if 

j  j-1 

Q.  (x*,y*  )  is  false,  Q.  (x*,y*  )  must  also  be 

xj  j  1j-l  j-1 

false. 

Case  2:  Supose  S.  is  a  test  statement.  Then 

Xj-1 

Qi  (x,y)  *  Q,  (x,y)  &  pv(x,y).  To  reach  cutpoint 
j  ^-1 
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i,  Pv  (x*,y*  )  must  have  been  true  so  if  Q.  (x*,y*  ) 
j  D  Xj  j 

is  false,  Q.  (x*,y*  )  must  also  be  false. 

Xj-1  j 

Case  3:  Suppose  S.  is  a  merge  statement.  Then 

Qj  (x,y)  =  Q.  (x,y)  v  Q.  (x,y) .  Hence,  if 
j  Xj“l  1 j~2 

Q.  (x*,y*  )  is  false,  then  both  Q.  (x*,y*  )  and 

j  j  Xj-1  j-1 

Q.  (x*,y*  )  must  be  false. 

j-2  j-2 

Proof  of  Theorem  4  (continued) 

If  we  assume  that  there  is  a  cutpoint  i^  such  that 

Q.  (x*,y*  )  is  false,  then  from  Lemma  4  it  follows  that  Q. (x*,y*.) 
1k  k  x 

is  also  false.  must  be  the  first  term  of  the  computational 

sequence.)  On  the  other  hand  we  know  that  q.  (x*,y*.)  is  true 

j  3 

for  all  j.  This  follows  from  the  definition  of  q.  But  q^x^)  is 
y=h(x)  and  if  Q  is  a  fixed-point  of  F,  then  we  must  have 

Q  (x,y)  =  (y=h  (x) )  . 

So  on  the  one  hand 

ql(x*,y*  )  =  (y*  =  h (x*) ) 

1  1 

is  true  but  on  the  other  hand 

Ql(x*,y*  )  =  (y*  =  h (x*) ) 

1  1 

is  false  so  that  we  have  a  contradiction.  Thus  we  conclude  that 
our  assumption 


(q(x,y)  3  Q(x,y) )  is  false 


5 .  CONCLUDING  REMARKS 


This  paper  has  dealt  with  arithmetical  programs  in  which 
the  data  type  consists  of  nonnegative  integers  and  the  operations 
are  those  of  recursive  arithmetic.  We  have  characterized  the 
computations  of  an  arithmetical  program  by  an  arithmetical  pre¬ 
dicate.  This  is  a  first-order  formalization  of  programs,  compared 
to  the  well-known  second-order  formalization  (e.g.  given  in  [9]). 
We  have  also  shown  that  arithmetical  predicates  are  powerful 
enough  to  express  invariant  assertions,  and  we  have  given  an 
algorithm  to  generate  invariant  assertions  for  arithmetical 
programs.  This  result  should  be  seen  in  contrast  to  Misra  [12] 
where  it  is  argued  that  the  "general  problem  of  generating  loop 
invariants  from  input  specification  is  impossible."  Although  it 
has  not  been  proven  formally,  the  time  complexity  of  our  algorithm 
is  a  polynominal  function  of  program  length.  Thus  arithmetical 
programs  furnish  a  clear  exception  from  the  implication  in 
Wegbreit [15]  that  in  the  general  case  the  synthesis  of  invariant 
assertion  may  require  exponential  time. 

Unfortunately ,  the  invariant  assertions  generated  by  our 
algorithm  are  quite  complex.  They  do  not  provide  any  insight 
about  the  computations  done  by  a  program,  but  essentially  re¬ 
express  the  computations  in  terms  of  arithmetical  predicates. 
Although  it  is  conceivable  that  these  predicates  can  be  simplified 
by  the  rules  of  logic  and  formal  arithmetic,  their  usefulness  in 
applications  such  as  program  verification  is  doubtful.  In  any 
case,  our  concern  in  this  paper  is  theoretical  —  in  showing 
the  solvability  of  the  assertion  synthesis  problem  for  arithmet¬ 
ical  programs.  We  would  like  to  emphasize  one  serious  problem, 
however.  Invariant  assertions  have  been  defined  in  the  literature 
purely  semantically.  For  example,  minimal  predicates  (Manna [9]) 
and  optimal  predicates  (Cousot  &  Cousot  [3]  )  have  been  defind  in 
terms  of  the  relations  they  ought  to  satisfy.  But  their  intended 
"practical  usefulness"  is  not  reflected  in  their  definition. 
Although  the  literature  abounds  with  examples  of  elegant,  concise 
assertions,  there  are  no  clear  criteria  to  specify  "nice"  asser¬ 
tions.  The  fact  that  our  synthesized  assertions  satisfy  the 
letter  of  the  definition,  but  not  the  spirit,  underscores  the 
inadequacy  of  the  definition. 
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